<html>
<head>
<meta http-equiv="content-type" content="text/html;charset=utf-8"/>
<title>DNMP - вопросы и ответы (FAQ)</title>
<link href="ice.css" type="text/css" rel="stylesheet"/>
</head>
<body>
<p><b>Distributed Network Messaging Protocol</b></p>

<p>Коммерческое использование только с разрешения автора.<br>
При использовании необходимо явно указывать ссылку на источник.</p>

<p>Sergey Bodrov, 2009-12-28</p>

<p><b>Вопросы и ответы</b></p>

<p>Здесь собраны вопросы и ответы, касающиеся протокола DNMP и его применения.</p>

<p>&gt; gribozavr</p>

<p><u>&gt; что плохого может сделать нод в масштабах сети? Как от этого защититься?</u></p>

<p>По поводу защиты - есть две меры, это рейтинг узла и отметка в паспорте, кто его выдал. Низкий рейтинг приводит к блокировке узла со стороны других участников, а отметка в паспорте позволяет предьявлять претензии к тому, кто пустил явного злодея в сеть.<p>

<p><u>&gt; Ещё: как-то мутно написано по поводу идентификации; то уникальный ИД в пределах нода, то ГУИД.</u></P>

<p>ID это часть адреса. Адрес выглядит как &lt;ID узла&gt;.&lt;ID точки&gt;. Проще говоря, это порядковый номер. GUID это уникальный глобальный идентификатор, по нему можно однозначно идентифицировать участника, даже если он сменил сетевой адрес. Адрес по GUID вычисляется эхо-запросом, который идет веером по всем узлам.</p>

<p><u>&gt; Сейчас предлагается древовидная конфигурация связей нодов? Ила всё-таки граф?</u></p>

<p>Рекомендуемая топология внутри сегмента - дерево. В принципе, допустимы и множественные связи, но их нужно настраивать вручную или полуавтоматически. Между сегментами топология пока не регламентирована.</p>

<p><u>&gt; <i>топология внутри сегмента - дерево</i> Очевидный недостаток, влияющий на время доставки сообщений и на нагрузку на узлы.</u></p>

<p>Это компромиссное решение. Сделать автонастройку маршрутизации и топологии подключения для тысяч узлов с неопределенной доступностью задача непростая. В реале такое обычно и не требуется. Кроме того, протокол не рассчитан на мгновенную доставку сообщений (хотя и допускает такое) и не ставит задачу максимального снижения нагрузки на транзитные узлы. Это не интернет, это скорее почтовая сеть.</p>

<p><u>&gt; если где-то всё-таки работает голубиная почта, то можно перенести идею AS. То есть, один нод может регистрирует от своего имени в основной IP-сети все ноды, которые "за ним".</u></p>

<p>В идеале, узлы должны иметь постоянную связь, а точки узла могут подключаться как и когда угодно. Если по техническим причинам нет постоянной связи между узлами, то лучше вынести эти узлы в разные сегменты.</p>

<p><u>&gt; 1. Плохой нод NA регистрирует пойнт PA. PA отключён. В это время кто-то отправляет PA файл и он падает на NA. PA перемещается и подключается к NB. Файл переливается на NB, но PA его не забирает. PA перемещается на NC. Файл снова переливается. Теперь PA перемещается между NB и NC, кушая их трафик.</u></p>

<p>Если у пойнта слишком низкий рейтинг, то он может оказаться отключенным от сети, а его паспорт (и все сообщения/файлы/прочее) удалены. Ему придется по-новой получать разрешение на включение в сеть.</p>

<p><u>&gt; 2. В ноде NX админ написал скрипт, который изменяет все проходящие сообщения.</u></p>

<p>Если эти изменения носят деструктивный характер (нарушают работу сети, искажают передаваемые данные), то узлу понижается рейтинг вплоть до исключения из сети. Вряд ли удастся автоматически вычислять такие вещи (кроме явных несоответствий стандарту или логике работы), поэтому должен быть и ручной способ выставления оценки узла. Решать проблему технически (шифрование, CRC, итд) считаю недостаточно эффективным.</p>

<p><u><i>&gt;&gt; Решать проблему технически (шифрование, CRC, итд) считаю недостаточно эффективным. </i><br>
&gt;И зря. Включаем публичный ключ в паспорт и получаем требуемое автоматически.</u></p>

<p>Это можно реализовать на прикладном уровне в случае необходимости. Структура паспорта вполне допускают добавление дополнительных полей с ключами, а структура сообщения допускает передачу произвольных бинарных данных (шифров). Делать же шифрование обязательным не вижу смысла. Я также отказался от контрольной суммы для пакетов, возложив проверку целостности на механизм передачи данных линка между точками. Протокол подразумевает, что данные передаются волшебным образом между двумя точками, но при этом допускает, что связь между точками не постоянна.</p>

<p><u>&gt; А вообще, попытаюсь повторить вопрос в более явной форме: чем это отличается от google wave? Тем, что локальное с авто-нахождением сервера? Так с avahi можно сделать автонахождение чего угодно, надо только 1 небольшой файл конфигурации сделать.</u></p>

<p>Я недостаточно хорошо знаю устройство Google Wave, увы: Видел только презентацию.</p>

<p><u>&gt; Ещё я не понимаю, почему вы (как мне кажется) полностью игнорируете тот факт, что сообщения будут передаваться через IP сети со всеми вытекающими особенностями. Или просто не переносите аналогии на этот протокол.</u></p>

<p>А каковы особенности передачи сообщений через IP сети? Если вас смущает безопасность, то можно поднять VPN-туннель между точками, или соединяться через SSL. Мой протокол не рассматривает проблемы доставки и целостности сообщений и не зависит от физической реализации канала между точками.</p>

<p>Протокол имеет некоторые общие черты с UDP/IP - обмен пакетами, адресоваными некоторому адресу/сервису. Но, в отличие от стека IP, нет деления на сетевые пакеты (3-й уровень OSI) и транспортными/сеансовыми протоколами (уровень 4 и выше). Это все в одном формате сообщения, что значительно упрощает реализацию.</p>

<p>Гляньте структуру сообщения - там несколько фиксированных полей для маршрутизации (адрес откуда и куда, пройденные узлы) и два динамических поля - одно для строковых параметров имя=значение, другое для произвольных двоичных данных. Я полагаю, что это весьма удобно для 90% случаев, когда не потребуется инкапсулировать в сообщение в виде двоичных данных нечто более высокого уровня.</p>
</body>
</html>